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1. Introduction 


The purpose of this grant is to investigate the use and impiementation 
of Ada (a trade mark of the US Dept, of Defense) in distributed environ- 
ments in which the hardware components are assumed to be unreiiable. in 
particular, we are concerned with the possibility that a distributed system 
may be programmed entirely in Ada so that the individual tasks of the sys- 
tem are unconcerned with which processor they are executing on, and that 
failures may occur in the underlying hardware. 

Over the next decade, it Is expected that many aerospace systems will 
use Ada as the primary implementation language. This Is a logical choice 
because the language has been designed for embedded systems. Also. Ada 
has received such great care in its design and implementation that it is 
unlikely that there will be any practical alternative in selecting a program- 
ming language for embedded software. 

The reduced cost of computer hardware and the expected advantages of 
distributed processing (for example. Increased reliability through redundancy 
and greater flexibility) Indicate that many aerospace computer systems will 
be distributed. The use of Ada and distributed systems seems like a good 
combination for advanced aerospace embedded systems. 

Our work under this grant up to this point indicates that the situation 
Is not as good as expected. . There seem to be numerous aspects of the 
language which make its use on a distributed system somewhat difficult. 
The issues are not raised directly from efforts to implement the language 
but from the desire to be able to recover, reconfigure, and provide contin- 
ued service In- the presence of hardware failure. 

Our work so far has consisted of: 



(1) A formal definition of the Ada tasking semantics. 

(2) An examination of the language (July 1982. version 9) to thoroughly 
uriderstand the various features. 

(3) The generation of a mQdel of the assumed underlying hardware system 
and the failures of that system which will be tolerated. 

(4) An examination of the Ada language with regard to its use and imple- 
mentation in the assumed environment. 

(5) The design of an experimental system that can be used to investigate 
the algorithms we expect to develop for the implementation of Ada. 

Each of these topics are discussed in the sections below. 

2. Formal Semantic Definition of Ada 

In order to be able to implement a language, it is Imperative that a 
precise definition of the language semantics be available. Semantic defini- 
tions of programming languages are relatively uncommon because existing 
methods for semantic definition are difficult to use and in some ways 
Inadequate. A semantic definition of Ada has been prepared for the Ada 
Joint Program Office (AJPO) using denotational semantics. This definition is 
quite difficult to read but its biggest problem is that the tasking and excep- 
tion semantics of Ada are totally absent from the definition. The reason Is 
that denotational semantic methods are not sufficiently powerful to describe 
tasking. 

Previous work at the College of William and Mary produced a semantic 
definition using H-graph semantics. Since that report, the Ada language 
has changed somewhat and the H-graph definition methodology has been 
revised considerably. The new definition which we have undertaken is a 



revision of the eariier work at Wiiiiam and Mary using the iatest versions of 
both Ada and the H-graph method. The current version of the definition is 
attached as appendix 1. 


3. Examination of the Language - General 

As a part of the activities under this grant, we participated as a 
volunteer review group for the July 1982 Ada definition. This effort was 

coordinated by AdaTEC as an attempt to generate comments from the 
United States about the revised language before the final version (which 
would be used for the ANSI canvass) was printed. We found the revised 
language definition document to be very different from the July 1980 version 
and chose to put all of our effort Into reviewing the tasking definition 
thoroughly rather than review the entire language definition superficially. 

The result of our review was a set of 35 questions which were dis- 
cussed at the meeting of the volunteer reviewers at the AdaTEC conference 
In Boston (June 1982). Our comments were well received and many were 
found to have substantial content. These were to be passed on to the Ada 
design team for consideration. A brief examination of the July 1982 Ada 
reference manual (denoted version 16) Indicates that our comments were 
either not received in time or were not acted upon since most of the 
language difficulties still exist. A copy of our questions is attached as 
appendix 2. 

In general our concerns about Ada are to do with time. Some exam- 
ples are; 

(1) The conditional entry call does not define 'immediately* and so we 

have no way of knowing how the call Is supposed to be implemented. 



There are several ways which are entirely different based on the 
current language reference manual definition. 

(2) The timed entry call does not define when the time for the call is to 
begin. There are again several different interpretations. Worse how- 
ever. is the fact that the timed entry call does not provide a useful 
facility for the programmer in its current form given any definition. The 
problem which it should address is the need to be able to time out 
easily once a rendezvous has begun rather that before it has begun. 

These issues demonstrate why a formal definition of Ada is so Important. 
We cannot decide exactly what is supposed to be implemented given the 
current language definition which is in English and therefore ambiguous. 
Imprecise, and Incomplete. Unfortunately, the issues with the conditional 
and timed entry calls, and with other language elements, are actually much 
more serious in a distributed system. 

4. Underlying Hardware Model 

Initially, we assume that communication between processors on a distri- 
buted system will be implemented using layers of software that conform for 
the most part to the ISO standard seven layer Reference Model. The 
hardware topology that is used for a distributed system need have very little 
impact on the programming of the system at the application layer level, in 
principle, provided the implementation knows how tasks are distributed to 
processors and how communication is to be achieved, the various tasks can 
synchronize and communicate at will with no knowledge of their location. 

To discuss implementation and recovery in the context here, we found 
it necessary to have an underlying hardware model. Our model assumes 



that a set of processors are connected to some sort of communications bus 
system which we do not define. The bus system couid be a ring, muitipie 
rings, a crossbar switch, etc. Peripherai equipment such as sensors and 
actuators are also assumed connected to the bus system, and the connec- 
tion is assumed to be provided by a microprocessor dedicated to the Inter- 
face. 

The kinds of hardware failure that we are concerned with are not 
addressed by the ISO protocol. The ISO protocol is concerned with minor 
communications failures such as dropped bits caused by noise, etc. Also, 
situations such as a processor ’slowing down* or Incorrectly computing 
results are not of Interest here (though they are Important never the less). 
We assume that such events are taken care of by hardware checking within 
the processor or similar. The only class of faults not dealt with elsewhere 
Is the sudden total loss of a processor or bus and these are the difficulties 
we will attempt to deal with. 

We feel that this hardware model and associated failure model is 
directly relevant to avionics systems but also seem very relevant to space- 
craft systems. Sophisticated unmanned spacecraft frequently make extensive 
use of computers (e.g. Galileo) but are unable to pay the weight and power 
costs of extensive redundancy (such as In quad redundancy or SIFT). 
Reconfigurabie distributed systems designed to cope with processor or bus 
failure is an attractive alternative. If the design includes higher processing 
power than Is absolutely needed, and tasks exist which are not essential to 
mission success, then some loss of hardware followed by reconfiguration 
may allow the mission to continue successfully. 



5. Ada on Unreliable Distributed Systems 


We are examining the Ada tasking facilities to see which ones can be 
supported and which ones have to be abandoned in the programming of 
distributed systems on unreliabie hardware. The restrictions have to be 
imposed because of the need to reconfigure foliowing hardware faiiure. 

A key probiem area is the association of processors with tasks nested 
within other tasks. Failure of a processor containing a parent task whose 
children are running on another processor leaves the children as 'orphans*. 
Such orphan tasks present a difficult problem for reconfiguration because if 
the parent is to be restarted on a different processor, the children will be 
recreated as the parent is elaborated. 

Another difficult problem area Is detection of hardware failure. The 
hardware may not know that It has failed. The only proposal that seems 
feasible at the moment is the use of software heartbeats within each pro- 
cessor that are software monitored In other processors. 


6. A System For Experimentation 

The confirmation that algorithms developed for use and implementation 
of Ada are valid is best achieved by experimentation. We propose to con- 
struct an experimentation facility for distributed systems using our depart- 
mental VAX n/780 computer. In the overall design, we Intend to have the 
VAX function as a programmable switch to which several smaller computers 
will be connected. The VAX will be programmed to simulate any bus struc- 
ture that is desired for connecting the smaller computers. In addition, the 
VAX can systematically and repeatedly Inject faults into the simulated com- 
munications and monitor the handling of the faults. In this way bus and 



processor failure can be simulated easily. At present, we are at the early 
design stage of the overall system and the switch software. 


7. Remaining Grant Activities 

During the remaining grant period, we are going to complete our study 
of the use of the language so as to provide a complete set of guidelines 
for writing Ada programs In the context of interest. At present, we antici- 
pate that the list of restrictions will be quite substantial. 

Once we have completed that study, we are going to look closely at 
implementation. This effort may be easier than at first thought. If software 
heartbeats are used, the responsibility for error detection and management 
of the reconfiguration will be at the level of the application software layer. 
The implementation can be fairly standard except for those primitives used 
to provide reconfiguration services. 

If software heartbeats are not used, the implementation will be much 
more involved because It must provide all the major aspects of the required 


fault tolerance. 



Appendix 1 


An operational model of Ada tasking has been devoloped using an 
H_graph notation developed in. *H_Qraph Semantics'. T.W.Pratt. Technical 
Report Department of Applied Mathematics and Computer Science. University 
of Virginia. Sept 1981. 

In the model each task is assummed to be running on a separate pro- 
cessor: communication between processes (and hence between processors) 
is by remote calls to kernel procedures. The run time state is described 
by an H.graph grammar (A). Every Instruction will ultimately be defined as 
a transformation of the run time state. 

The transform COMPILE (B) translates an Ada text into an intermediate 
form consisting of a list of declarations and a list of executable statements 
(ie transformations of the run time state). Execution of the intermediate 
form proceeds in two steps. First elaboration of the declaration list, and 
second, execution of the statement list. 

An example of Ada text (C) and the intermediate form obtained by the 
application of COMPILE (D) is Included. 



A 


network ::= 

[ tNETWORKl 

-<node_ld>-> network_node 
{-<node_ld>-> network_node 1 

1 

network_node ::= 

[ [NETWORK_NODEl 

-name-> [ <node_id> 1 
-processor-> processor 
-communicatlons_interface-> [ [COMM] 

-proc_export-> proc_lnfo 
-proc_import_queue-> *plq: QUEUE( proc_lnfo ) 
I 

-kernel_proc_code-> [ [KPCODEI 

-<kproc_name>-> code 
{-<kproc_name>-> code } 

1 

-process-) process 

1 

processor ;:= 

[ [PROCESSOR] 

-next_lnstructlon-> lnstruction_pointer 
-timer-) (-[TIMER_HARDWARE ] 



-set-> t <tlmer_status> ] 


-delay-> t <tlme> 1 

-transfer_address-> lnstruction_pointer 

1 

-flags-> t CFLAGSl 

-user_pgm_suspended-> [ <boolean> 1 
-lnhlbit_tlmer-> [ <boolean> 1 
-lnhibit_abort-> [ <boolean> 1 
-lnhibit_exception-> t <boolean> 1 
-check_lmmedlate_rendezvous-> t <boolean> ] 

1 

-network_nod©-> [ network_node 1 
-kproc_lnfo-> proc_lnfo 

1 

instruction_polnter ::= [ tIPl 

-lnstruction-> [ code_node 1 
-code_block-> t code 1 

1 


proc_lnfo ::= 

t [ PROCJNFO 1 

-to-> [ <node_ld> 1 
-from-> [ <node_id> 1 


-kproc_name-> [ <name> I 



-parameters-> KEYED_LIST( <lnteger>.arb_node ) 

1 

code ::= LIST( code_node ) 

code_node ::= instruction_node I branch_node I LIST( code_node ) 

lnstructlon_node ::= [ tlNSTRUCTION_NODe 

-transform-) [ <transform_ld> 1 
-arguments-) KEYED_LIST( <lnteger),arb_node ) 

1 

branch_node ::= [ [BRANCH_NODEl 

-condition-) function_node 
-alternatives-) KEYED_LIST( <lnteger>.code ) 

1 

functlon_node t [FUNCTION_NODEl 

-function-) [ <functlon_ld) 1 

-arguments-) KEYED_LIST( <lnteger).[ arb_atom 1 
-result-) [ arb_atom ] 

1 


process ::= I [PROCESS] 


-process_ob|ect-) process_object 



-proc_lmport_queue-> **plq 


1 

process_ob)8Ct ::= [ [PR0CESS_0BJECT1 

-next_instructlon-> . lnstruction_polnter 
-actlvation_record_stack-> STACK( activatlon_record ) 

-load_module-> [ load_module 1 

1 

actlvatJon_record ::= task_activatlon_record S subprogram_actlvation_record I package activation record 

task_activation_record ::= 

[ rrARI 

-user_data-> user_data 
-system_data-> system_data 
-eiaboration_data-> elaboration_data 

1 

user_data 

[ tUSER_DATAl 

-iocais-> — ailocated by eiaboration 
-non_locais-> KEYED_LiST( <name>,[<nesting_ievei>I ) 

1 

system_data ::= 


[ [SYSTEM DATAl 



-my_phone_#-> processlng_unit 
-state-> [ <state> I 


-context-) [ [CONTEXT! 

-ref_stack-> t display 1 
-wlth_llst-> [ 1 

-use_llst-> ( 1 

1 

-exceptlon_llst-> LIST( <exceptlon_name> ) 

-governor-) processlng_unit 
-dependent_task_llst-) LIST( dependent_task_lnfo ) 
-#dependent_tasks_not_termlnated-) [ <lnteger> 1 
-#nolsy_tasks_ln_dependent_task_tree-) [ <lnteger) ] 
-entry_called-) t <entry_name) 1 

-entry_llst-) KEYED_LIST( <entry_name).entry_llst_node ) 
-llst_of_handlers-) handlers_llst_node 
-ready_to_rendezvous_llst-) LIST( entry_name ) 
-nestlng_level-) [ <lnteger> 1 


1 

display KEYED_LIST( <nestlng_level),processlng_unlt ) 
dependent_task_lnfo ;:= 

[ [ DEPEN DENT_TASK_INF01 

-processor-) processlng_unlt 
-terminated-) [ <boolean) 1 
-tree_qulet-) ( <boolean) I 



1 


entry_list_node ::= 

[ [ENTRY_LIST_NODE] 

-state-> t <state> ] 

-transfer_address-> [ lnstruction_polnter ] 

-queue-> QUEUE( entry_queue_node ) 

1 

entry_queue_node ::= I [ENTRY_QUEUE_NODEl 

-processor-> processlng_unlt 

-parameters-> KEYED_LIST( <lnteger>,arb_node ) 

1 

handlers_llst_node ."= 

[ [HANDLERS_LIST_NODEI 
-in_handler-> [ boolean 1 

-llst-> KEYED_LIST( <exception_name>.instructlon_polnter ) 


processlng_unlt 

[ tPROCESSING_UNm 

-network_node-> [ <node_id> I 
-tar-> ( task_actlvatlon_record 1 


1 



elaboration_data ::= [ [ELABORATION_DATA] 

-task_activatlon_data-> task_list_node 
-allocator_execution_data-> task_tlst_node 

1 

task_list_node [ (TASK_LIST_N0DE1 

-#_non_allocated_tasks-> t <lnteger> 1 
-#_non_active_tasks-> [ <integer> 1 
-llst-> KEYED_LIST( <task_name>.task_lnfo ) 

1 

task_info ::= t tTASKJNFOl 

-name-> full_ld 

-processor-) [ processlng_unlt 1 

-allocation_completed-> [ <boolean> ] 
-actlvatlon_completed-> [ <booiean> 1 

-load_module-> [ load_module 1 

1 


subprogram_actlvatlon_record ::= 

[ [SARI 

-ld-> fulLId 
-context-) display 

-user_data-) user_data 
-body-) subprogram_body 
-return_address-) lnstructlon_polnter 



-<jependent_task_llst-> LIST( dependent_task_info ) 
-#_dependent_tasks_not_termlnated-> t <integer> 1 
-task_acttvation_data-> task_llst_node 
-allocator_executlon_data-> task_llst_node 

1 

load_module ::= 

[ [L0AD_M0DULE1 

-module_ld-> fuJI_ld 
-entries-> LIST( entry_node ) 

-body-> task_body 
-context_of_body-> display 
-govemor-> processing_unlt 
~actlvator-> processlng_unit 

1 

entry_node :;= [ [ENTRY_N0DE1 

-name-> full_ldent 

-range-> range 
-formal_params-> formal_part 

1 

range ::= t [RANGE! 


] 


-low-> [ <lnteger> ] 
-hlgh-> t <integer> 1 



[ [FULL_IDENTI ] 


fulljd ::= 

-id-> [ <ldentifier> 1 
-level-> t <nesting_level> 1 

1 

body subprogram_body 

ltask_body 

subprogranri_specificatlon :;= t [SUBPROQRAM_SPECIFICATION] 

-id-> [ <ldentlfier> 1 

-level-> t curr_level I 
-params-> formal_part 
1 

formal_part ::= LIST({parameter_specification} ) 

parameter_speciflcatlon ::= [ tPARAMETER_SPECIFlCATION] 

-ld_llst-> identlfler_llst 

-level-> [ <lnteger> 1 

-mode-> mode 
-type-> type_mark 
-valu 0 -> code 


I 



mode 


[IN] I [IN OUT] I [OUT] 


subprogram_body ::= [ [SUBPROGRAM_BODY] 

-speclflcatlons-> subprogram.specification 
-declaratlons-> declaratlve_part 
-statements-> code 

-exceptions-> LIST( (exception_handler) ) 

1 

task_body ::= [ [TASK_BODYl 

-name-> full_ld 

-declaratlons-> declarative_part 
-statements-> code 

-exceptions-> LIST( exception_handler ) 

1 


exceptlon_handler :;= [ [EXCEPTION_HANDLERl 

-name_list-> LIST( excepilon_choice ) 
-handlers_code-> code 
1 


exceptlon_cholce ::= [ exceptlon_name I I [ OTHERS ] 


QUEUE(X) 



[ [QUEUE! 


-flrst-> [ QUEUE_ELEMENT( X ) 1 
-last-> [ QUEUE_ELEMENT( X ) 1 

1 

QUEUE_ELEMENT( X )::= [# ] S 
[ [QUEUE_ELEMENT! 

-head-> t X ] 

-rest-> [ QUEUE_ELEMENT( X ) 1 


KEYED_LIST( <KEY>, MEMBER ) ::= 
t # 1 I [ [KEYED_LISTI 

-<KEY>-> MEMBER 
{ -<KEY>-> MEMBER ) 

1 


LIST( MEMBER ) ::= [#1 I [ [LIST! 


1 


( — > MEMBER ) 
"> t#l 


STACK( KIND ) ::= [#] i I [STACK] 

-head-> [ KIND 1 
-tail-> [ STACK( KIND ) 1 


1 


<node_ld> ;;= <ldentifler> 
<name> ::= <ldentlfier> 
<kproc_name> ::= <ldentlfler> 
<entry_name> <ldentifler> 
<transform_ld> ::= <identifier> 
<function_ld> ;:= <ldentifler> 
<tlmer_status> ::= ON i OFF 
<time> ::= <lnteger> 

<boolean> ::= TRUE I FALSE 



treunsform [COMPXLE] 

— > *BDA_TE3Cr: in [ <subprogranubody> ] 

— > *MAIN_BO0Y; out subprogrcua-body 

var 

*COMPXm_TIME_INFO : compile_time_info := 0 [#] 

compile_tiine_info : :«= [ [COMPIIiE_'PIME_INFO] ] 

-level-> t <nestinq_level> ] 
-context— > context 

] 

context KErZED_LIST( { 1 .. n} ,name_table ) 

name_tal)le : LIST( name_table_itein ) 

naine_tal)le_item : [ [NBME_TABtE_ITEM] ] 

-id-> full_id 
-type_name-> type_name 
-declaration-) [ basic_decl 2 u:ation ] 

1 

full^id : J- [ [FDLI,_ID] ] 

-id-> [ < identifier) ] 

-level-) [ <nesting_level) ] 

I 


<nesting_level) : := <integer) 


type_inarlc 
basic_declarat ion 


see productions 
in the pair graimn 2 u: 



KEXED_LIST( { <KEY> }, MEMBER ) : ; = 

[#] I [ [KEXED_LIST] 

-<KESr>-> MEMBER 
{ -<KEY>-> MEMBER } 

] 

MST( MEMBER )::=[#]! [ [LIST] 

{ — > MEMBER ) 

— > [#] 

] 

— curr_level represents an integer with value *COMPILE_TIME_IlIPO/ . level 

begin 

paurse 

*ADR_TEXTs[ <subprogranLJx)dy> ] 
generate 

*MAIN_BODY; subprograntJ>ody#l 
*COMPIIiE_TIME_IIIFO ; subprogranLjx>dy#2 

paLir grammar 
basic_declaration i :» 

ob j ect_dec lar at ion 
I type_declaration 
I subprogranL_declaration 
I taisK-declaration 


I except ion_declaxat ion 



ba^ic.declaration 


ob j ect_declaxat ion 
I type_declaxation 
I subprograiQ_declaxation 
I tau3X_declaj:ation 
I exceptionL_declaxatlon 


object_declaration j j* 

identifier_list : [constant] subtype_indication [:= expression] 


object_decXau:ation s :» #1 *a:[ [ OBJECT JOECIARATION] 

-id_list-> identifier_list 
-type-> subtype_indication 
-level- > [ curr_level ] 

-value-> expression 

-allocated-> [ <boolean> ] 


] 

#2 add_name_to_name_table( curr_level, identif ier_list , subtype_indicatio 


identifier_list ;:»> identifier {, identifier } 


identifier^list ::-LIST( s:{[ <identifier> ]} ) 



s » ( identifiers in RHS of IflS production ) 

; 

type_declaxation ; 

type identifier [discriminant_^eurt] is type_definition 

type_decleuration ::=> #2 *a; type_definition 

add_najne_to_name_table( curr_level, identifier, type_definition, [ *a] ) 


type_definition : := access_type_definition 
type_definition ; ;= access_type_definition 


siibtype_indication ::=» type_mark [constraint] 

Subtype_indication : ;= [ [SUBTYPE_IHDICATION] 

-type_info-> type_marlt 
-constraint- > constraint 


] 



type_ioeu:k ; :» type_name | subtype.name 

type_mark : ; » type_name | subtype.name 

if type_naine = pdtype then 
type_niark [ [PREDEFINED] 

-pdtype-> [ <pdtype> ] 

1 

else 

*tn ;= DOCATE( type_naine ) 
type_jnau:k : := *tn/type_info 
endlf 

I 

acces3_type_definition : := access subtype_indication 


access_type_definition ; !=■ [ [ACCESS_TYPE_DEFINITION] 

-type_info-> type_mark 
-const raint-> constraint 

— defining_unit-> curr_unit 


1 


declarative_jpourt [beisic_declaxative_itein) {later_declaiative_item} 



decleu:ative_j>eurt ; := [ [DECIARATXVE_^ARr] 


-baLsic_items-> IiIST( { basic_declarative_item } ) 
-later_items-> LIST( { later_declarative_item } ) 


I [ [#] ] 


basic_declarative_item ; ;= basic_declaxation 
basic_declaxative_item ; ;=• basic_declaration 


later_declarative_item : 

body 

I subprogram_declaration 
I tasfc^declarat ion 

later_declaxative_item : := 

body 

I subprogram_declaration 
I task^declaration 


body : : 


subprogram_body 



I tasKJbody 


body : := 


subprograiQjsody 
I tasKJxjdy 


simple.name 
I indexed_component 
I selected_component 


name : 

fulX_id 

I indexed-component 
I selected_component 


task^simple_name_l simple_name 
teU3k_simple_name_l : ; - full_id 


tasK_simple_name_2 ; simple_name 



task^siniple_naine_2 : #1 fuH_id 

#2 curr_level := curr_level + 1 

add_entry_info_to_name_table( curr_level, full_id ) 

— add entry names and parameter specifications 

— from the tcLsk specification to the 

name_tahle 

s 

simple_name : := identifier 

fuli_id : := [ [FULr,_IDl 

-id-> [ <identifier> ] 

-level- > [ n ] 

] 

! 

indexed-component : name( expression {, expression } ) 

indexed_component [ [INDEXED_COMPONERT] 

-name-> name 

-indices-> KEYED_LIST( {< integer >}, expression ) 

1 
; 


— n is the level found by searching 
— the surrounding contexts for the 

— identifier. 



selected_component ; :=» nan». selector 

selected_component [ [SEIiECTED_COMPO!*EBT] 

-name-> name ^ 

» 

-selector-> selector 

1 

; 

selector ::= simple_name 

I all 

selector : := full_id 

I [M^l 
» ■ 

allocator ; := new type_mark 

allocator : := [ [ALLOCATOR] — > 

[ REP( type_meu:}c ) ] &t — > 

[ ALLOC( fit ) ] &ptr' — > 

[#] 


] 



sequence_of_statements : :» statement { statemant } 

sequence_o£_statements : : = IiIST( ( statement } ) 

« 

# 

statement : simple_statement 

I compound_statement 

statement : simple_stateinent 

I compound_statement 

; 

simple_statement : : = null^statement 

I aissignment_statement 
I delay_statement 
I raise_statement 
I procedure_caH_statement 
I return^statement 
I entry_caH_statement 
I abort_stateinent 

simple_statement : := null^statement 

j assignment_statement 


I delay_statement 


I rai.se_statement 


I procedure_call^statement 
I retum_statement 
I entry_call^3tatenient 
I abort.statement 


compoundLstatement ;:= accept_statement 

I select_stateinent 

CompoundLstatement ; accept_stateinent 

I selectLStatement 


null_statement : := null; 

nullLStatement ; :«■ [ [llULIc_STATEHENT] — > 
[ NOOP ] — > 

[#] 


1 


assigmnent^statement : varial>le_naine expression; 

assigraaent_statement ; [ [ASSl(aQfEZfr_STA.TEMERT] — > 

C REP( variable.name ) ] &z — > 
expression &e — > 

[ ASSl(ai< &z,&e ) ] — > 

[#] 

] 

; 

retum_statement :s*» return [expression]; 

retum_3tatement : [ [RETORR_STa'rEKEHT] — > 

expression &e — > 

[ RETORN( &e ) ] — > 

— > [#] 

1 


subprograsu^eclaration s := subprograin_specification; 

subprograsudeclaration : != subprogranuspecification; 



subprogram_specification_l : := procedure identifier [ f onnal_paurt ] 

subprograin_specification_l ; #1 *a:[ [SUBPBOGRAH_SP£CIFICATION] 

-id-> [ <identifier> ] 

-level- > [ curr_level ] 

-params-> fonnai_part 

1 

#2 add_name_to_naine_list( curr_level, identifier, subprogram, [*a] ) 


subprogram_3pecificatioru2 : := #1 [ [SDBPRDGRMLSPECIFICATION] 

-id-> [ <identifier> ] 

-level-> [ curr_level ] 
-paxams-> formalj>art 
1 

#2 curr_level ;= curr_level + 1 


formal^art : ( parameter_specification {; parameter_specification) 
formal_part : := LIST( {parameter_specification> ) 


parameter_specification ; identifier_list : mode type_mark expression] 



pcu:ameter_specification : #1 *a:[ [PM»METEIL.SPECIFICATIOfI] 

identifier_list 
-level-> [curr_level + 1] 

-mode-> mode 
-type-> type_marlc 
-value- > ei^ression 

1 

#2 eidd_nanie_to_naiiie_list( curr_level+l , identifier_list , [ *a] ) 


mode : s= [in] 1 in out | out 
mode [IN] 1 [IN OUT] | [OUT] 

; 

subprogramJJody : : “ 

subprogram_speci£ication_2 is 
[declarative_paxt ] 
begin 

sequence_o£_statements 

[exception 

except ion^handler 
{exception_handler} ] 


end [designator]; 



sviljprograin_Ix>dy : #1 [ [SDBPROGI»M_BODY] 

-specifications- > subprograsuspecifications 
-decleu:ationa-> declarative_part 
-statements- > [ prelude — > 
overture — > 

sequence_of_statements — > 
epilog — > 

[#1 

1 

-exceptions-> I*IST( {except ion_handler} ) 

1 

#2 curr_level :=> curr_level - 1 

procedure_ceJ.lwStatement ; ;= procedure_name [ actual_parameter_part] 

procedure_call_statement ; :» [ [FROCEDURE_caLI<_STATEMEHTl 

actual^arameter_part apareuns — > 
f REP( procedure_name ) J &p — > 

[ CAIiL( &p,&params ) ] — > 

[#] 


1 


actuaX_parameter_part : ( paraineter_association {, paxameter_association} ) 
actual^_parameter_part ; := IiIST( pauran»ter_association ) 


parameter_cU3Soclation : [ formal^axameter =>] actual_peu:ameter 

parameter_association [ [PARftMETERJVSSOCIATION] — > 

actual_paxameter — > 

[ add_to_paxameter_list ( paranuinf o , param_id , mode , type ) ] — > 

filled in from 

— corresponding formal parameter 
t#l 

1 


formal_paxeuneter : := parameter_simple_name 


formaX-pa ramet er : :» paxameter_simple_name 


actual^_parameter : :« expression 


— param_id 


I variable.name 



|type_jaarlc ( vcu:lable_name ) 


actua2_parameter : := [ CWili] — > 

ei^ression &e — > 

[ f ill_ia_paxan»_info( &e , ’VALUE ’ , null ) ] 

[#] 

1 

I [ [HEP] — > 

C REF( variable_name ) ] &n — > 

[ f ill_in_paxam_info( &n, ’ADDE’ ,nuU)] 

C #1 

1 

I [ [REFT] — > 

[REF( variaLble_nan« ) ] &n — > 

[REF( typejuark ) ] fit — > 

[ f ill^in_pau:ain_info( &n, ’ TADDR' , fit ) ] 

[#1 

] 


task_declaratlon : :■= task-specification; 


taak_declaration ; := taisk-specification; 



[ decleurative_part ] 
begin 

sequence_o£_statements 

[exception 

exception_handler 
{exception_handler} 
end [taisK_siiiiple_name]; 


taslOKKjy ::= #2 *body: [ [TASK_BODY] 

-name-> task_siinple_name_2 
-declarations-> decl 2 u:ative_part 
-statements-> [prologue — > 
overture — > 

sequence_of_stateinents — > 
epilog — > 

[#] 1 

-exceptions-> LIST( except ion^handler ) 

1 


find_in_name_list( tasK_siniple_naiae_2 , *n ) 
»n/body ’ : => taslOJody ' 
curr_level curr_level - 1 


entry_declau:ation t j 


task^specification : ; 


task [type] identifier [is 
(entry_declaration} 

(representation-clause) 
end [tcisK.simple_ncune] ] 

load_module_teii^late : := #2 *a:[ [LOAD_JtODOLE_TEMPLATE] 

-inodule_id-> [ [FOIil 4 _ID] 

-id-> [ <identifier> ] 

-level- > [ curr_level ] 

1 

-entries-> LIST( {entry_declaration) ) 

-body-> [#] 

-context_ofjDody-> [#] 

-governor-> [#] 

-activator-> [#] 

] 

add_name_to_najne_list( curr_level, identifier, task, [*a] ) 


taskjxjdy : ; = 


tcusk body taisk^siinple_naiiie-2 is 



entry identifier [ ( discrete_reUige ) ] [ f onnaX,part ] ; 

» 

entry_declau:ation : #l [ [EIITKy_pECLARATION] 

“id-> identifier 
-level-> [ curr_level ] 

-range- > rainge 
-fonnaL_part-> formal^^peurt 

] 

#2 add_name_tp_name_list(curr_level, identifier, entry ) 

; 

entry_caH_statement_l : entry_neune[actual^axaineter_.pa3rt]; 

entry_call^statement_l : :=• [ [EWnw_CALIi] — > 

[KEF( entry_name ) ]SE,&pssr — > 
actuai_paxam_part &p6u:ains — > 

[ entry_cal^_proc( &pssr,&E,&paxains ) ] — > 

[#] 

1 


ent ry_call_s t at ement_2 : : - entry_name [ actual^aramet er_part ] ; 



entry_call^3tatement_2 s := [ [ENTRY_CRUi] 


— > 


t®EP( e*'try_name ) ]&£,&pssr — > 
actualjparam_part fiparaios — > 

[#I 

1 

; 

accept_statement_l : j" 

accept entry_aimple_name [(expression)] [formal^axt] [ do 
8equence_of_statements 
end [entry_siinple_name] ]; 

accept_stateinent_ls != [ [ACXEPT.STATEMENT] — > 

[REP( entry_simple_name ) ] &n — > 
expression &e — > 

[REP( fonaaIv_part ) ] &f — > 

[ accept_proc(fie,fif,sn) ] — > 
sequence_of_statements — > 


[ end_of_rendezvous ] — > 


accept_stateB«ent_2 : := accept_part_l accept_part_2 


accept_part_l : entry_simple_name [ (ei^ression) ] [ f ormal^art ] 

accept_psurt_2 ; := [ do sequence_of_statements end [entry_siinple_nan«] ] 

accept_statement_2 : :=> accept_part_l accept_part_2 
accept_part_l; :=» [ [ACCEPT_JARP_1] — > 

[KEP( entry_3iji>ple_naE[ie ) ] &n — > 
expression &e — > 
formal_part &f — > 

[#] 

] 

accept_part_2: ;= [ [ ACXKPT_paRT_2 ] — > 

[ accept_proc(&e,&f,&n) ] — > 
sequence_of_statements — > 
t end_of_rendezvous ] — > 

[#1 

] 


delay_statement_l : ;= delay simple_expression; 

delay_statement_l :;= [ [ DELAY_STATKMfNT_l ] — > 

% 

simple_expression &d — > 

[ set_timer ( &d,*a ) ] — > 

[ state_)}ecomes( ’ suspended: at delay ' ) ] — > 





1 


delay_statement_2 : delay siinple_ei^ression; 

delay_statement_2 : [ [DELftY_STATEMENT_2 ] — > 

simple_expression &d — > 

[#] 

] 

select_statement selective_wait 

I conditional_entry_call 
I timed_entry_call 

select_statement selective_wait 

I conditionaL_entry_call 
I timed_entry_call 


select ive_wait : 


select 



select_eQternative 


{or 

select_altemat ive } 
else 

sequence_of_statements 
end select; 

select ive^wait : :«» [ [SELECTXVE_WAIT_STATEMEST3 — > 

t set_up_temp_data^str ] — > 

IiIST( { select_altemative} ) — > 

[ [BRAHCHl 

-condition-> [checK_if_any_open_guard] 
-alternatives- > [ [KEYED_LIST] 

-true-> [ perfornuselect ] 
-false- > sequence_of_statements 

] 

] — > 

[ release_temp_data_str ] — > 

**end_of_solect ; [#] 

1 


select ive_wait ; z- 
select 


se lect_alt ernat ive 


{or 


select_cQternatlve } 
end select; 

selective_wait : := [ [SELECTIVE_WAIT_STATEMEHT] — > 

[ set_up_temp_dataustr ] — > 
liIST( { select_alternative } ) — > 

[ [BKARCH] 

-condition-> [check^if_any_open_guard] 

-alternatives- > [ [KEYED_LIST] 

-true-> [ perform_select ] 

-false- > [ HAISB_BXjCCTTIOII( • SELECT ERROR’ ) ] 

] 

] — > . 

I 

[ release_temp_dataustr J — > 

»*end_of_select ; [# ] 


select_alternative ; := [ when condition => ] 

se lect ive_wait_alt ernat ive 

select_altemative : := [ [SELECT.JILTERHATIVEJ — > 

[ [BRANCH] 

-cond it ion- > condit ion 


-alternatives-> [ [KEYED_LIST] 



] — > 


1 


-true-> selective_waLit_alternative 
-false-> [#] 

] 

[#] 


select ive_wait_altemative : := accept_altemative 

j de lay_alt ernat ive 
I texminate_alternative 

selective_wait_alternative : := accept_alternative 

I delay_alternative 
I terminate_alternative 


au;cept_altemative ; ; = accept_statement_2 [sequence_of_3tatements] 
accept_statement_2 : := accept_paxt_l accept^art_2 

accept_alt ernat ive ::=> [ [ACCEPT_JVIiTERRATIVE] — > 

accept_ part_l &n &e — > 


»a 



*b: accept_part_2 


> 


sequence_o^statements — > 

* *end_of_se lect 

*a; [put_on_open_guards_list( *b ) — > 

[#] 

] 


delayualternative_l : := delay_statement_2 [sequence_oC_statement3] 

delay_alternative_l ss>= [ [DEIAY_m.TERNATIVE] — > 
delay_statement_2 &d — > 

*a 

*c z sequence_of_statements — > 

* *end_of_se lect 

•a;[ update_smallest_opetx_delay( &d,*c ) ] — > 

[#1 

1 


tenninate_alternative : := terminate 


terminate_alternative : z- [ [TERMINATE _ALTERNATIVE] 


— > 



[ set_open_temiinate_flag ] — > 


t#] 

1 


conditioneLl_entry_call ; : = 
select 

entry_caLll^statement_2 
[ sequence_of_st atement s_l ] 
else 

sequence_of_statements_2 
end select; 


conditional^entry_call : := [ [CONDITIONAL_ENTKr_CALL] — > 

entry_call^statement_2 &E,&pssr,&parains — > 

[ request_rendezvous (&£,&pssr,$params) ] — > 

[ [BRANCH] 

-condition-> [ rendezvous_posslble( ) ] — > 
-alternatives-) [ [KETED_LIST] 

-true-) sequence_of_statements_l 
-false-) sequence_of_statements_2 

] 

1 — > 

[#] 


1 



time<i_entry_call : : 


select 

entry_call^statement 
[ sequence_of_st atements_l ] 
or 

delay_statement_2 
[ sequence_of_statements_2 ] 
end select; 

timed_entry_call : :=> [ [TIMED_^NTRY_caLLJ — > 
delay_stateio6nt_2 &d — > 

»b 

*a; sequence_of_statements_2 

*end 

*b;[ set_timer( &d,&a ) ] — 
entry_call_statement_l — > 
sequence_of_statements_l — > 
*end;[#] 

1 


abort_3tatement : : = abort tasK_naine { , taisk^name ) ; 



abort_statement ::= LIST( {ABOKT_TASK( tasX_name ) }) 

ABOier_TASK(X) ;:= [ [ABORT] — > 

[HEF(X) ] &n — > 

[ abort_exec( fin ) ] — > 

[#1 

1 


exception_aeclaxation identifier_list : exception; 

except ion_declarat ion : := [ [EXCEPTlON_tiiECLARATlON] 

-id_list-> identifier_list 
-type-> [EXCEPTION] 

1 


except ion^handler ; :=■ 

when except ion_cho ice ( | except ion_choice } =»> 
sequence_of_statements 

except ion_handler : [ [EXCEPTION_HANDLER] 

-name_list-> LIST( exception_choice ) 


-handlers_code- > sequence_o£_stateinent s 



1 


except ion_choice ; ;= exception_name 


I others 


except ion_choice ::•=> [ except lon_name ] | [ 


raise_statenient :s«» raise [ except ion_name]; 

raise_statement [ [RAISE_STR'rEMENT] — > 

[REF( except ioiv_name ) &n - 
[ raise.exception ( &n ) ] 
C#] 


OTHERS ] 


> 


— > 


end COMPXLE 



. procedure PTRST is 
tasX type SIMPLE is 

entry X( I : in integer ) ; 
end SIMPLE; 

task type COMPUTE is 

entry Y ( I: out integer ) 
end COMPUTE; 

S: SIMPLE; 

C;COMPUTE; 

I : in'teger ; =6 ; 

task body SIMPLE is 
A: integer :=10; 

B: integer; 
begin 

# 

accept X (I:in integer); 

B A + I; 
end X; 
print(B); 
end SIMPLE; 

task body COMPUTE is 
C ! integer ; =3 ; 
begin 


S.X(C); 



accept Y(l:out Integer) 


I C + 2; 
end Y; 

end COMPUTE; 

begin — FIRST 
C.Y(I); 

I I + 5; 
PRIHT(I); 


end FIRST; 



[ [SnBFROGR2ttf_BOD7] 


-specif icat ions- > [ [SUBPROGRftM-SPECIFICATION] 

-id-> [FIRST] 

-level-> [0] 

-parans-> [#] 

] 

-decleurations-> [ [LIST] — > 

[ [OBOECT_DECLaRATION] 

-id_liSt-> [ [LIST] — > [S] — > [#] ] 
-type-> [ [StIBTIPE_INDICATION] 

-type_info-> *lmt SIMPLE 
-constraint- > [# ] 

] 

-level-> [1] 

-value-> [#] 

] — > 


[ [OBJECT_DECLARATION] 

-id_list-> [ [LIST] — > [C] — > [#] ] 
-type-> [ [SDBTYPE_INDICATION] 

-type_info-> *ltmCOMPUTE 
-constraint- > [#] 


] 

-level-> [1] 


-value-> [#] 




-statements-) [ [LIST] — > 
prologue — > 
overture — > 

[ [ENTRY_CALL] — > 

[ REF( C,1),(Y,1)] &pssr,&£ — > 

[REF( 1,1 ) ] &params — > 
[entry_calI^roc(&pssr,&£,&peo:a]as)] — > 
[#] 

] — > 

[ [ASSIGSMENT_STATEMERT] — > 

[ REF( (1,1) ) ] &addr — > 


[ [EXPKESSION] — > 



[REF( (1,1) ) ] &a — > 

[KEF( 5 ) ] fib — > 

[ADD( fia,Sb )] fic — > 

w 

] — > 

[ ASSICXl( fiaddr,fic ) ] — > 

[#] 

1 — > 

[REF( 1,1 ) ] fiOUt — > 

[PRINT(fiout) ] — > 
epilog — > 

[#] 

1 

-except ions-> [#] 

] 

*lBrt:SIMPIiE: [ [LOAD_MODDtE_TEMPLA.TE) 

-inodule_id-> [ [FOLI,_ID ] 

-id-> [SIMPLE] 
-level-> [1] 

] 

-entries-> [ [LIST] — > 

[ [ENTRY_DECLARATION] 

-id-> [X] 


-level-> [2] 



-range-> (#] 


-fonnal^_part-> [ [LIST] — > 

[ [PABAMETER^SPECIFICATION] 

-idLlist-> [ [LIST] — > [I] — > [#] ] 

— level-> [2] 

-mode-> [IN] 

— type-> [ [PREDEFINED] 

-pdtype-> [INTEGER] 

1 

-value->[#] 

I — > 

[#] 

] 

I — > 

[#] 

-body-> *taskjKJdy_siinple 
-context_of Jx>dy-> [#] 

-governor-> [#] 

-activator-> [#] 


•ImtCOMPtrrE: 


[ [LOAD_MODULE_TEMPLATE] 

-module_id-> [ [FULL_ID ] 

-id-> [COMPOTE] 


-level-> [1] 


] 



-entries-> [ [UST] — > 


[ [ENTRy_PECIiftRATION] 

-id-> [Y] 

-level-> [2] 

-range-> [#] 

-fonnal_part-> [ [IiIST] — > 

[ [PAR2«ETER^SPECIFIC3VnON] 

-id_list-> [ [LIST] — > [I] — > [#] ] 

-level-> [2] 

-mode— > [ODT] 

-type-> [ [PREDEFIKED] 

-pdtyp^> [ INTEGER] 

] 

-value->[#] 

] — > 

C#] 

] 

1 — > 

[#] 

-body-> *tasJOx>dy_compute 
-context_of_Jxjdy-> [#] 

-governor- > [#] 

-activator-> [#] 


*taslO>o<3y_simple;[ [TASIL.BODY] 



-name-> [ [PDLlt_lD] 

-id-> tS] 

-level-> [2] 

] 

-declaration3-> [ [MST] — > 

[ [0BJECT_DECIARATI0N1 
-id_list-> [ [LIST] — > [A] — > [#] ] 
-type-> [integer] 

-level-> [2] 

-value-> [10] 

] — > 


[ [OBJECT_DECLARATIOH] 

-id_list-> [ [LIST] — > [B] — > [#] ] 

-pdtype-> [INTEGER] 

] 


-level-> [2] 
-value-> [#] 




] 


statements- > [ [LIST] — > 
prologue — > 


overture — > 



[ [ ACCEPT_STATEMiiNT ] — > 


CREF( X,1 ) ] &n — > 

[REP( 1,2 ) ] &f — > 
[accept_proc(&f,&n)] — > 

[ [ASSICTMENT.STA'i'KMKNT] — > 
tREF( B,2 ) ] &addr — > 

[ [EXPRESSION] — > 

[REP( A,2 ) ] fiopl — > 

[REP( 1,2 ) 1 &op2 — > 

[ADD( opl,op2 ) ] &e — > 

[#] 

] ~> 

[ASSIGN( &addr,&e ) ] — > 

[#] 

I — > 

[end_of_rendezvous] — > 

[#1 

I — > 


[REP ( B,2 ) ] &out 
[PRINT( &out ) ] — > 

[#1 


1 


-exceptions-> [# ] 



*t oisIO>o<3y_coinput e : [ [ TASK_BODY ] 

-name-> [ fF 0 U 4 _ID] 

-id-> [C] 

-level-> [2] 

] 

-declarations-> [ [LIST] — > 

[ [OBJECT_DECLARATION] 

-id_list-> [ [I.IST] — > [C] — ■> [#] ] 
-type-> [ [FREDEFINEDl 

-pdtype-> [INTEGER] 

] 

-level-> [2] » 

-value-> [3] 

] — > 

[#] 

] 

-statements- > [ [LIST] — > 
prologue— > 
overture — > 

[ [ENTHT_CALL] — > 

[REF( S,1),(X,1)] &pssr,&£ — > 

[REF( C,2 ) ]&params — > 

[entry_call^roc( spssr, &£, &par^uns ) ] — > 

[#] 


1 — > 


[ [ACCEPT_STa.TEHENT] — > 


[REF( Y,1 ) ] an — > 

[REF( 1,2 ) ] &f — > 
[accept_proc( — > 

[ [ASSICamENT.STATEMENT] 
[REP( 1,2 ) ] fiaddr — > 

[ [EXPRESSION] — > 

[REP( C,2 ) ] aopl — > 
[REF( 2 ) ] &op2 — > 

[ 2VDD( opl,op2 ) ] &e - 

[#] 

] — > 

[2VSSIGN( &addr,ae ) ] — > 

[#] 

1 — > 

[end_of_rendezvous] — > 

[#] 

] — > 

epilog — > 

[#] 


-except ions- > [ # ] 


Appendix 2 


Questions on the Ada '82 Language Reference Manual. 



Questions and comments about wrong, confusing, unclear, and incomplete 
parts in the tasking sections (mainly chapter 9 but some of chapter 11) of 
intra-canvass Ada Reference Manual. 

(1) General 

The examples appearing In the 1982 reference manual are no more 
than those in the 1980 version. Most are examples of proper statement 
syntax only. There are places in the manual where even a simple 
example would clarify more than the volume of text. The reference 
manual needs more examples; at least one for each language feature. 
Where an example refers to or uses a previous example, an explicit 
reference should be given. 

(2) Chapter 9. page 1. paragraph 1. line 1 

It is stated that the execution of a program which contains no task 
procedes according to the rules described by the manual less chapter 
9. In a multiprogrammed system, main programs look remarkably like 
tasks executing independently. Is the main program a task (with no 
entries) or not? , 

(3) Chapter 9. page 1. paragraph 1. line 4 

•The effect of ... a program Is defined in terms of a sequential execu- 
tion of its actions in some order...* What does "some order" mean? 
We realize that the Intended order Is that traditionally found In Imple- 
mentations of Algol-descended languages with rearrangements and 
optimizations restricted as in chapter 11. However, the manual does 
not specify that, it says “some order.* 

(4) Chapter 9. page 1. paragraph 2. line 4 

We know that two tasks are synchronized at the beginning and end of 
a rendezvous, and that tasks are synchronized with their declaring 
parent at their activation, but are there other places? For instance, 
are tasks “synchronized* during execution of an ABORT statement since 
in that case they are not operating independently. This is the first 
occurrence of the term “synchronize." It is a technical term in the 
definition of Ada semantics. It must be precisely defined. 

(5) Chapter 9. page 1, paragraph 4. line 3 

There are three kinds of program units of which programs can be 
composed according to chapter 9 but four according to chapter 7. 

(6) Chapter 9, page 1. paragraph 4, line 3 

What Is the Intent of a program unit (the term Is not defined)? If I 

write a program unit which consists solely of a task unit or generic 
unit, what can I do with it? (Dare we ask “What is a main program?*) 

(7) Chapter 9, page 2 section 9.1 paragraph 3 

"task [type] identifier [is ... end [simple_name]l* What is the distinction 
that is being made between an Identifier and a simple_name? Is the 
reference manual alluding to the symbol table operation and to the 
relationship between the lexical analyzer and parser of a particular 
compiler? 



(8) Chapter 9. page 2 section 9.1 paragraph 5 

*...the body can ... be used tor the execution ot tasks designated by 
objects of the ... task type." From reading descriptions elsewhere in 
the manual it seems to us that the term "values of objects" would be 
more appropriate here. The continuation of the fiction that a task object 
and its value are somehow different when we are told that tasks behave 
as constants, seems silly, it does provide consistency with the descrip- 
tions of other kinds of objects and their values but can add confusing 
verbiage to an already confusing chapter (besides, it contributed to this 
mistake in the manual Itself). 

(9) Chapter 9, page 3 section 9.1 paragraph 1 

We had an argument about when or whether it would be legal for a 
task to refer to itself, especially by its type identifier. We eventually 
came up with several valid cases, but the point here is that the 
manual slips the capability in and certainly does not expand on it. The 
material explaining how a task type name serves as a task name is 
very cryptic and could do with some elaboration. A separate notation 
for self reference would be nice. 

(10) Chapter 9. page 4 section 9.2 paragraph 1 

We were under the impression (and the first note in the designated 
section seems to support this) that task types could be passed as gen- 
eric actual parameters at instantiations of generic units, yet this sec- 
tion, besides the note. Ignores such usage. Was it ever decided 

whether omission in the reference manual constituted a prohibition? 

(11) Chapter 9. page 5 section 9.2 note 1 

The business of modes allowed and disallowed for generic parameters 
whose types are task types Is very confusing. This note needs elabora- 
tion or It needs to be moved to an appropriate place in the chapter 
on generics. Why are tasks not allowed as actual parameters 

corresponding to generic formal parameters with mode IN since tasks 
by definition are "constant"? 

(12) Chapter 9. section 9.3 

The manual is very explicit about when task objects declared in a 
declarative part get activated (not before and not after the following 
BEGIN), and about when task objects created via an allocator get 

activated. When do task objects created via an allocator in the initiali- 
zation of an object of an access type In a declarative part get 

activated? This is important In terms of understanding what is com- 
pleted and what Is terminated should an exception occur during the 
activation of one of these tasks. We do not understand when these 
tasks get activated! We are also concerned about the apparent incon- 
sistency in the fates of declared and allocated tasks which experience 
exceptions during their activations. 

(13) Chapter 9 section 9.3 

In 9.3 activation is defined to be the elaboration of the declarative part 
of a task body. When does a task proceed after Its activation has been 
completed? NOTE; In July 1980 Ada, section 9.3 states. ' Each task 
can continue its execution as a parallel entity once its activation is 



completed.' Why was this omitted? 


( 14 ) 


(15) 


(16) 


(17) 


(18) 


(19) 


(20) 


( 21 ) 


( 22 ) 


( 23 ) 


Chapter 9. page 21 section 9.11 

Why is task synchronization between activator and activatee only men- 
tioned in shared variables? We need a detinition of synchronization. 

Chapter 9. page 7 section 9.3 

References at the end of section 9.3 (and probably elsewhere) still have 
’*?* in them. Will they be replaced? 

Chapter 9. page 6 section 9.3 paragraphs 1 & 4 
When tasks are being activated after a begin, if the activation raises an 
exception the task becomes completed. On the other hand paragraph 4 
states that if a task has been created by the execution of an allocator 
and an exception is raised during its activation then the task becomes 
terminated. Are the cases really different and if so why? NOTE; Ch 11 
p8 si 1.4.2(d) says that the task would be completed in both cases. 

Chapter 9, page 6 section 9.3 paragraphs 1 & 4 
"other tasks are unaffected* Does this include dependents or does it 
refer back to 'these tasks' - the tasks being activated? This is not 
clear. 


Chapter 9. page 8 section 9.4 (paragraph 2 ... Example! 

Use of “unit" vs. “task* is extremely confusing. Text should replace 
'certain unit' by 'parent unit'. The meaning here can be completely 
missed very easily (some of us did on first reading). 

Chapter 9, page 7 section 9.4 paragraph following (c) 

The new definition of dependency needs further explanation. We suggest 
adding a note explaining that because of the definition of termination 
and the rules about leaving subprograms and blocks, only tasks defined 
In a unit or contained in an inner package need be checked for termi- 
nation. 


Chapter 9, page 8 section 9.4 Example 
Example is not clear because we don't know where G.ALL was activated. 
We suggest that comments should be ammended to read "await termi- 
nation of G.ALL if it was ever activated no matter where." 

Chapter 9, page 10 section 9.5 (last paragraph before the 
example) 

This needs to be rewritten more clearly. Chapter 11 section 11.5 con- 
tains a clear explanation of the situation which could be copied or 
referenced. 

Chapter 9, page 11 section 9.5 note 2 
What if an entry has OUT parameters but the accept has no statements 
— what happens if you use the parameters? 

Chapter 9, page 12 section 9.6 
Typo in PACKAGE CALENDAR; 2009 should be 2099 
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Chapter 9. page 13 section 9.6 note 1 
Heed your note and make the correction (we would have liked to have 
seen this explanation). 

Chapter 9. page 14 section 9.7.1 paragraph 2. line 1 
The line: "A selective wait must contain at least one alternative ... ' 
should read: *A selective wait must contain at least one select alterna- 
tive ... ‘ since that is the non^terminal used in the syntactic definition. 

Chapter 9. page 14 section 9.7.1 paragraph 2 
Parenthesized comments in this paragraph specifying the combinations of 
terminate, delay and else parts allowed in a select statement should not 
be parenthesized — they are too Important. They should be separately 
stated and elaborated. 

Chapter 9. page 15 section 9.7.1 dashed paragraph 1 
When does the delay start? is It safe for the programmer to assume 
that the total amount of time required for the select statement if no 
rendezvous is posssible. is no greater than that given in the delay 
statement or is the time needed to evaluate any guards not included in 
the execution time of a select statement? 

Chapter 9. page 16 section 9.7.2 paragraph 1. line 1 
Use of the word immediately is confusing. A conditional entry call may 
take an arbitrary amount of (communication) time to execute even if no 
rendezvous occurs. 

Chapter 9. page 17 section 9.7.3 

What does the delay include In a timed entry call? is it the time on 
the entry queue only, or does it include ’message transmission’ time 
to/from caller from/to callee? If the latter, how do we Implement this 
when one task is on Earth and the other on Mars (this Is not a flip- 
pant question)? Also, if no scheduling algorithm is assumed by the 
language definition, how can the ’correct’ execution be guaranteed? 
We assume a timed entry call with delay 0 really means the program- 
mer Is prepared to wait 0 seconds on the entry queue. It is clearly 
impossible to have any other meaning because an entry call always 
takes some time. Thus we assume delay I means wait for a duration of 
I on the queue. Is this correct? 

Chapter 9, page 18 section 9.8 rule 

The word “sensibly" is not appropriate In this context. It. is far too 
ambiguous for a document puporting to be a language definition. 

Chapter 9, page 18 section 9.8 last paragraph 
If two tasks rendezvous, one with priority 5 and the other without 
defined priority, is it a valid implementation for the rendezvous to 
always occur with priority PRIORITY'LAST+1 ? 

Chapter 9, page 20 section 9.10 

It is impossible to guarantee that a task named In an ABORT statement 
will not proceed beyond an accept (etc.) after the aborting task thinks 



( 33 ) 


(34) 


(35) 


the aborted task has been marked abnormal. If the tasks were running 
on different physical processors the communication time for the abort 
message could be arbitrarily long, is It legitimate for a task that has 
been marked abnormal to execute an ABORT statement? The manual 
Implies 'yes'. 

Chapter 9. page 20 section 9.10 

What happens to the calier/callee In a rendezvous when the 
callee/caller is aborted? (This is explained in Chapter 11 but should be 
In section 9.10 also) 

Chapter 9. page 21 section 9.11 

This section as a whole and the usage of the 
SHARED_VARIABLE_UPDATE procedure In particular is not at all clear 
— we need an example. Also you should point out that use of shared 
variables makes programs non-portable because this facility may not 
cover ail types in an implementation. 

Chapter 9. page 20 section 9.10 (general) 

Can the task below be terminated by an ABORT statement once the 
rendezvous has begun? 


TASK TRAP IS 
ENTRY X; 

END: 

TASK BODY TRAP IS 
BEGIN 

ACCEPT X DO 
LOOP 
NULL- 

END LOOP: 
END; 

END; 



